Portals, in particular web portals, are a common way to access information in the age of the Internet and cloud computing. Portals can provide access to information networks and/or sets of services through the World Wide Web and other computer networks. Often portals provide a single point of access to data and applications. A portal can present a unified and personalized view of information to users. In many implementations, portal applications can include web application views designed as a portal. Portals are capable of presenting data of multiple sources like web applications in a single web interface or browser. In addition to regular web content that may appear in a portal, portals provide the ability to display portlets (self-contained applications or content) in the browser user interface. Portals can also support multiple pages with menu-based or custom navigation for accessing the individualized content and portlets for each page. An individual portal view may be specified by a portal configuration. The portal configuration can include a portal definition such as a file including Extensible Markup Language (XML), portlet definition files for any portlets associated with the portal, java server pages (JSPs), web application descriptors, images such as graphics interchange format files (GIFs), deployment descriptors, configuration files, the Java archive (JAR) files that contain logic and formatting instructions for the portal application, and any other files necessary for a desired portal application.
Speed of information display after requesting through, e.g., a click on an icon is one of a series of key user requirements. Service-level agreements (SLA) formally define the quality of such a portal service. Amongst others, an SLA can set a performance target for web portals. In particular, an SLA can refer to the mean delivery time of pages or parts thereof of a web portal.
Web portal servers usually operate in one of two distinct rendering modes:
(1) Server-side aggregation (SSA) mode: The server performs the aggregation of all mark-up fragments that amount to a web portal page. Afterwards, the complete page is sent to the client in response to a previous request.
(2) Client-side aggregation (CSA) mode: The client performs the aggregation of all mark-up fragments that amount to a web portal page. In response to a client request, the server delivers mark-up that enables the client to load the mark-up fragments that are necessary to complete the web portal page.
Each of the above modes has advantages but also brings along certain disadvantages. For example, the number of requests required to render a web portal page in SSA mode is reduced to a minimum, whereas the CSA mode can result in a large number of single requests because of reloading mark-up fragments one by one. On the other hand, the SSA mode can cause higher initial response times than the CSA mode, because the page aggregation must be completed on the server before it responds to a client request.
FIG. 2 shows rendering and aggregation in a client (CSA) according to the state of the art. A web client 202 and a web portal server are in communicative contact to each other. On the client-side, a web portal 206, enabled by a client-side aggregator 208, enables displaying of information. On the server-side, a web portal engine 210 provides access to the information. The information may come from a widget1 application 224, a portlet1 application 226, or a portlet2 application 228. A page navigation application 222 may be implemented for accessing ordinary web-pages and navigating through them.
On the client side, different pages or fragments 212, 214, may be displayed along with widget1 216, portlet1 218, and portlet2, 220. Reference numerals 230, 232, 234, 236 refer each to an information request from the client-side aggregator 208 to the web portal engine 210 and a response of the web portal engine 210 to the client-side aggregator 208. The information elements are shown as small boxes with different filling patterns. The client-side aggregator 208 aggregates all these information elements and renders them for display in the web portal 206 of the web client 202.
A similar diagram may be drawn for SSA. In that case, a combined already aggregated portal page combining all information elements would be sent over from the web portal engine 210 to the web portal 206. A client-side aggregator 208 would not be necessary because not any client side aggregation would be required.
However, in today's high performance computing environment, a compliance with defined delivery times of services becomes more and more common. Available solutions do not allow, or have only limited capabilities, to work according to SLAs (service level agreement). Thus, there is a need for information and application performance management according to predefined SLAs in the portal.